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NEED FOR VALIDATED ARCHITECTURES 


A need exists for architectural concepts that have been validated such 
that their physical implementation in hardware and software will meet 
the quantitative missions requirements such as 

cost 

weight, volume, power 
throughput performance 
transport lag 

mission success probability 
mission availability 


and also be responsive to qualitative requirements such as 
expandability 
graceful degradation 
technology insertion 
damage tolerance 


AIPSIS 


• A COMPUTER SYSTEMS PHILOSOPHY 

• A SET OF VALIDATED HARDWARE BUILDING BLOCKS 

• A SET OF VALIDATED SERVICES AS EMBODIED IN SYSTEM 
SOFTWARE 


TO ACHIEVE 


DISTRIBUTED FAULT -TOLERANT SYSTEM ARCHITECTURES FOR 
A BROAD RANGE OF APPLICATIONS 
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GOAL 


. PROVIDE THE KNOWLEDGEBASE which will 
allow achievement of VALIDATED fault-tolerant 
distributed computer system architectures, 
suitable for a broad range of applications, 
having failure probability requirements to 10E-9 
at 10 hours 


AIPS PROGRAM HISTORY 


Phase I 1983-1984 
Requirements Survey 
Technical Survey 
Architecture Synthesis 


(NASA, JPL, Airframers) 

(NASA, DoD, Industry, Academe) 

(CSDL monitored by Peer Review Group) 


Phase II 1986-1986 

Functional & Detailed Design of Building Blocks 
Reliability & Performance Modeling of Building Blocks 


Phase 1111986-1993 

Emphasize Validation to Verify AIPS Attributes 
Focus on: Engineering Model for ALS 

High Throughput/Highly Reliable Army Fault Tolerant Architecture 
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AIPS BUILDING BLOCKS: HARDWARE 



INTERFACES 


[ IQS I Input/Output lnt*rf»c*s 

[£gj lnt*r-Comput*r Interface Saquwicar 


AIPS BUILDING BLOCKS: SOFTWARE 


LOCAL SYSTEM SERVICES: 

Ada Real Time Operating System 
FTP Redundancy Management 
Local Time Management 

INPUT/OUTPUT (I/O) SYSTEM SERVICES: 
I/O User Communications 
I/O Redundancy Management 

INTERCOMPUTER (1C) SYSTEM SERVICES: 
Ada Distributed Synchronous 
Communications 
1C User Communications 
1C Redundancy Management 

SYSTEM MANAGER: 

Function Allocation & Migration^ 

System Redundancy Management 
Global Time Management 
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AIPS EXAMPLE CONFIGURATION 


I/O NETWORKS 



FEATURES: 


APPROPRIATE FUNCTION RELIABILITY 
LOW FAULT TOLERANCE OVERHEAD 
GROWTH CAPABILITY 
Ada OPERATING SYSTEM 
REDUNDANCY TRANSPARENT TO USER 


DISTRIBUTED SYSTEM CONTROL 


• AIPS Operates in an overall framework that can be characterized as a limited 
form of a fully distributed multicomputer system 

- Each GPC has the Resources to Operate Autonomously 

- Each GPC in Steady State is Assigned to a Unique Set Of Functions 

- Local Operating System in Each GPC Provides Local System Services 
of Initialization, Task Scheduling and Dispatching, I/O Service, and 
Local Redundancy Management 
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SYSTEM COMPLEXITY MANAGEMENT 

A1PS Architecture Designed to Hide System Complexity from Applications 


• System Services, as Implemented In Hardware and Software, Manage 
Distributed Resources and Hardware Redundancy 


• Distributed Computation Deliberately Separated from Fault Tolerance 


• Exact Consensus Between Processes and Exact Consensus Between Bus 
Transmissions Simplifies Fault Detection and Isolation 


• Hardware Mechanization of Fault Detection and Isolation Simplifies 
Redundancy Management 


• AIPS Architecture Designed to Facilitate Congruent Data Flow in Redundant 
Processors and Between GPCs 


PROGRAM ACCOMPLISHMENTS 

• Produced an Analytical and Empirical Knowledgebase for Validation of AIPS 

Architecture ana Building Blocks 

- Architecture Design Rules and Guidelines 

- Analytical Reliability, Performance, Availability and Cost Models 

- Empirical Reliability and Performance Data 

• Developed and Demonstrated Distributed Engineering Model 

-Vaiidatability, Distributed computation, Mixed redundancy, Fault tolerance 
(processors, networks, interfaces), Damage tolerance, Graceful degradation, 
Expandability, Transparency of fault tolerance to applications programmer, 
Low fault tolerance overhead, Performed Laboratory Test and Evaluation 

-Demonstrated AIPS Building Blocks 
3 Triplex FTPs and 1 Simplex Processor 
Triplex Intercomputer Network, Mesh I/O network 
System Services Software (>100,000 Lines of Ada Code) 
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ACCOMPLISHMENTS (cont’d) 


• COMPLETED MULTIPATH REDUNDANT AVIONICS SUITE MPRAS 2102 
AIPS TASK FOR ADVANCED LAUNCH SYSTEM 

- AIPS ENGINEERING MODEL OPERATIONAL 

- GOVT/INDUSTRY REVIEW 10/89 

- 4 REPORTS PUBLISHED SEPT. 1991 

-SUBMITTED AIPS/ALS UPDATE FOR ALS/ADP REVISION D PLAN 

- PRODUCED A 20 MINUTE AIPS VIDEO 

• COMPLETED "HANDS OFF’ CASE / AIPS DEMO FOR CODE GENERATION 
AND EXECUTION OF ATOPS 737 AUTOPILOT 

• PUBLISHED NUMEROUS REPORTS AND PAPERS 

- ATTACHED 29 REPORT BIBLIOGRAPHY 


AIPS CURRENT FOCUS 

• Base Program 

- AG&C/CASE/AIPS Demo (NASA Funding) 

- Develop Authenticated Protocols for Inter-System 
Communication (SDI Funding) 

• Army Fault Tolerant Architecture (Army Funding) 

• Fault Tolerant Parallel Processor Development 

- Common-Mode Fault Study 

- Optical Fault Tolerant Interconnection Networks 

• Terminate CSDL/ AIPS Contract 

- Contract Completed 9/30/92; All Tasks Completed by 
9/30/93 
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AG&C/CASE/AIPS DEMONSTRATION 



FLIGHT SIMULATION 


Army Fault-Tolerant Architecture (AFT A) 


• Helicopter Night-Time Nap of the Earth Operations 

• Integrated Flight Controls and Image Processing 

• High Throughput/Ultra Reliable Fault-Tolerant 
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Fault Tolerant Parallel Processor 


High Performance Voting Architecture. Fully connected fiber optic network 
between processor groups. 

Tolerates arbitrary failure modes (Asymmetrical faults). 

Uses many Processing Elements (PE’s) for high throughput 

Uses redundant PE’s for high reliability. Data Voting Architecture 

Can trade Throughput for reliability or availability in real-time. 

Uses Non Development Items (NDI) PEs, backplanes, power supplies, 

I/O for improved suportability 

Allows mixed redundancy and heterogeneous processing resources. 


AFTA Characteristics 

□ Processing Elements 

Support for 3 to 40 PE's per Cluster (FTPP). 

680x0’s, 80960's, MIPS R3000's, TMS320x0, etc... 

PE’s in the AFTA are groupeo into redundant Virtual groups 
to achieve fault tolerance. 

Virtual groups can be simplex, triplex, quadraplex, or quintuplex. 

Static Virtual group configuration determined by reliability and availability 
analysis. 

□ Network Elements provides: 

100 Mbit/sec fiber optic interchannel links. 

Standard bus interface to Processing Elements. 

(Mil-STD-344, Pi-bus, Futurebus, Safebus, etc...) 

Time management primitives for architecture (synchronization). 

Reliable data Communication services ( Voting, Source congruency). 

Maps physical processing sites into virtual groups (VIDs). 
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AFTA Characteristics cont'd 


□ Software main components: 

OT Ada-based operating system with real-time extensions. 

Preemptive rate group scheduler. 

Periodic task communication between Virtual groups. Pro-defined 
communication services. 

Performance Penalties from Redundancy Management and Operating 
systems functions minimal. (10% - 15%) 


POSIX Real-time operating system interface standard (IEEE PI 003). 
LynxOS Version being evaluated now (FY93). 


□ I/O controllers 

Fault-Tolerant Data bus (Auth. protocols) 
1553, JIAWG FT data bus, VME, etc.... 


AFTA Physical Architecture 
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AFTA Virtual Architecture 



Qutdruptu Shnpioi Tripbx Quradruplu Tripitx TripUi Smptex Simplex Sfevpfcz 
with VO with I/O wit) W) 


AFTA Program Status 


Three phase program: 


I. Conceptual study - Completed in FY91. Analytical modeling, 
feasibility studies, requirements acquisition, preliminary design. 

II. Detailed design. FY92. Design hardware and software architectures. 

III. Detail design and evaluation. FY93. Complete HW and SW architecture 
desfans, begin performance evaluation activities of AFTA in relation 

to TF/TA application. 


Major deliverables: 

1. All procured hardware and software. 

2. All software and hardware documentation 

3. Final written comprehensive report. 

4. CECOM will receive an AFTA for evaluation In FY95. (Loan from CSDL) 
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SELECTED APPLICATIONS OF AIPS 


Unmanned Undersea Vehicle (UUV) - DARPA 

- Under DARPA sponsorship, Draper designed and built two 
UUVs, each of which is autonomously controlled by a triplex 
FTP based on the AIPS architecture 

- Both vehicles have undergone extensive sea trials without 
any significant FTP related problems 


Seawolf SSN-21 Ship Control System - US Navy (NavSea) 

- A quadruply redundant FTP, based on the AIPS 
architecture, has been militarized and packaged in SEM-E 
modules to perform the "swim-by-wire'’ functions onboard 
the SSN-21 Seawolf nuclear attack submarine 


SELECTED APPLICATIONS OF AIPS (Cont.) 


SDIO Battle Management / C3 - US Army (SDC) 

- Aquadruply redundant FTP with attached processors 
(FTP/AP) was delivered to Army Strategic Defense Command 
for evaluation as a Battle Management Computer 


Army Fault Tolerant Architecture - US Army CECOM 

- An AlPS-based Army Fault Tolerant Architecture (AFTA) has 
been developed for the heiicopter terrain avoidance/terrain 
following flight control application for the Army 
Communications and Electronics Command 
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SELECTED APPLICATIONS OF AIPS (Cont.) 


GPALS Engagement Planner - US Army (SDC) 

- The brassboard of Army Fault Tolerant Architecture is being 
fabricated for the GPALS (Global Protection Against Limited 
Strikes) Engagement Planner application for the Army SDC 


MAGLEV Command and Control Computer - DOT 

- A fault-tolerant, fail-safe computer architecture using the 
Al PS-developed design for validation methodology was 
developed for the US Maglev (magnetically levitated) 
transportation system under DOT sponsorship 


AIPS TECHNOLOGY TRANSFER 


* Tech Aerojet FTP 

- Under a contract from NASA MSFC Tech Aerojet selected 
the AIPS Fault Tolerant Processor architecture for the engine 
control application on the National Launch System 

- Under a subcontract from Tech Aerojet, Draper helped 
them define an Intel i 960 -based triplex Ft P’s fault tolerance 
related hardware for fabrication by Tech Aerojet 


. Martin Marietta Astronautics FTPP 

- A study was done by Draper to apply AIPS technology to 
Martin's aerospace needs under a contract from MM 

- Following the study, a quadruply redundant Fault Tolerant 
Parallel Processor (FTPP) was delivered to Martin for use in 
various IR&D and sponsored projects 
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FY92 ACCOMPLISHMENTS 


During FY92, three major tasks were active: 

* Army Fault Tolerant Architecture (AFTA) 

- Detailed design of the AFTA hardware and software was completed. 

- The Network Element, the only hardware development item in AFTA, 
which Is responsible for fault tolerance related functions and message 
passing between processors, was designed and breadboarded. 

- Breadboard of the NE was fabricated and tested; the Scoreboard, 
one of the two NE cards which was designed using VHDL, worked the 
first time without any errors. 

- A 2-volume report documenting the conceptual study phase of AFTA 
was publisher 


FY92 ACCOMPLISHMENTS 


• Authenticated Protocols-Based Inter-Computer and I/O Networks 

• A detailed design of the Transport Layer, patterned after the Open 
Systems Interconnect (OSI) model, of tne inter-computer communication 
software was completed. 

- Key generation, signaturing and message authentication algorithms were 
produced, coded and optimized in C and Assembly languages. 


* Hosting of AGN&C Algorithms using CASE on AIPS/FTPP 

- Martin Marietta Astronautics, Denver produced Matlab scripts of 
advanced guidance algorithms designed at NASA LaRC. 

- Draper Lab, in collaboration with Martin, chose a subset of Matlab scripts 
for interfacing with the CASE tool. 

- Modification of the CASE tool to accept Matlab scripts was started. 
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FUNDING 



FY92 and Prior 

FY93 TOTAL 

SDIO/ALS 

$3.23 M 


5DIO/BMC3 

$1.22 M 

$150 k (Authen Proto) 

ARMY/AVRADA 

$2.30 M 
$6.75 M 


NASA RC FUNDING 

$1.45 M 

$50 k (AG&C Demo) 
$403 k (CASE) 

TOTALS 

$8.2 M 

$830 k $9.03 M 
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Systems Architecture Branch 
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Langley Reseat ch Center 


Automatic Programming Subsystem 

• Accepts functional specifications 

• Generates source code (Ada, C) 

• Generates documentation 


• System architecture: 



L 




Systems Architecture Branch 
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Benefits of the ASTER Approach 


Reduce development time 


• Reduce errors 


• Code and documentation always agree 

• Decouple engineering design and software design 

• Reuse engineering designs 

• Facilitate and reduce testing 

• Provide an open, extensible architecture 


Systems Architecture Branch 
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Software Development Techniques 
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Engineering Design 
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Demonstrations 

• Large Gap Magnetic Suspension System (LGMSS) 

- C code running on an embedded Silicon Graphics workstation 

- Passed CDR and delivered to customer 

• B737 Autoland Flight Control System 

- Ada running on Draper’s Fault Tolerant Processor in conjunction with a 
FORTRAN simulator on a MicroVAX 

- Ada running on Draper's Fault Tolerant Parallel Processor In conjunction 
with a FORTRAN simulator on a MicroVAX 

- C currently being hosted on Draper's Transputer FTP 

• Guidance and Control System for a Mars Lander 

- Ada running on VAX in conjunction with FORTRAN simulator 

• Inertial Fiber Optic Gyro/Standy Attitude Indicator (IFOG/SAI) 

- Ada running on a MIPS R3000 

• Inertial Reference System for Deep Submergence Rescue 
Vehicle 

- Model upgrade from FORTRAN to Ada on a VAX 

V, , , T ■ • ■ Systems Architecture Branch —S 


*fUA£A Langley Research Center — — — > 

Demonstrations (cont.) 

• Space Station Control System 

- Applied for documentation purposes 

- Ada and C code generated 

• General Dynamics Electromechanical Actuator 

- Ada and C cede generated 

• Martin Marietta Load Relief Filter 

- Ada code running on SUN and VAX 

- C code running on a variety of workstations, PC's & computers 

• Boeing B737 Yaw Damping System 

- Ada running on Draper FTP for N-version software experiment 

- C running on Draper FTPP 

• Autonomous Exploration Vehicle 

- Ada running on SUN workstation 

- C running on SUN workstation 

• Shuttle's Ascent First Stage Guidance 

- Implemented by Martin Marietta under IR&D 

- Ada executed and tested on two environments, including a 
shuttle software simulator 

Systems Architecture Branch 
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Objectives of AGN&C Demonstration 


• Demonstrate the cooperative use of complimentary 
technologies within the Flight Systems Directorate 

• Drive the development of ASTER 

- Vector/Matrix/Quaternion Operations 

- MATLAB™ Integration 

- Libraries 


Systems Architecture Branch 
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Approach 


■\ 


• Develop Finite Element Numerical Optimal Control 
(FENOC) Algorithm 

• Develop flight software specification (MATLAB) 

• Input specification into ASTER 

• Generate Ada code 

• Test code 

• Execute on target architecture 


Systems Architecture Branch 
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"NASA Langley Research Center 


Integrated AGN&C Demonstration 



Demonstration 


Code 

Systems Architecture Branch 


r f\1AEA Langley Research Center i ■ ■ ■ > 

MATLAB Integration 
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Summary 


• ASTER is a production quality code generation system. 

• ASTER has been demonstrated on a variety of "real" 
applications. 

• The AGN&C demonstration has identified ASTER 
enhancements. 

• The AGN&C demonstration will illustrate the cooperative 
use of complimentary technologies within the Flight 
Systems Directorate. 


w- — Systems Architecture Branch 
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PANEL DISCUSSION 


Howard Stone 

I would like to have the panelists come up and be seated. While the panelists are coming let me 
add that we [the GNCTC] are going to be compiling the presentation material of this workshop 
into a NASA CP [conference publication]. We plan to send a copy of that CP to all who are 
interested in receiving a copy. If you are interested in receiving that publication please sign in on 
one of the yellow pads out in the lobby. We will also attempt to pick up the essence of this panel 
discussion for inclusion in the CP. To do that we are going to be videotaping the panel 
discussion. We do invite audience participation and to facilitate the taping process, we need to 
have everybody use a mike. If you have a question or a comment, wait for a mike to get to you. 
These mikes that are on the table are portable and we can move them around the room. Also, we 
have invited people to feel free to come up and use the view graph projectors in this discussion. 

If you do that, then please put on the lapel mike. 

Let me now introduce our panel. Your participation is very much appreciated and the GNCTC at 
LaRC would like to thank each one of you [the panelists] for coming and being willing to 
participate. 

From right to left, our first panelist is Tom Richardson from Boeing Defense and Space Group in 
Seattle. Tom has worked in control systems synthesis, aircraft stability and control, aeroelastic 
modeling, and flight control architecture designs. He has been responsible for developing 
techniques to achieve highly reliable digital flight control systems using advanced architectures, 
fault detection, and redundancy management techniques. He is currently manager of Boeing's 
Defense and Space Group flight control technology organization and is the program manager for 
the Air Force Strategic Flight Management Contract and the NASA fly-by-wire contract that 
Felix [Pitts] discussed earlier. Tom we appreciate you coming. 


Our second panelist is Clint Browning from Honeywell in Clearwater, Florida. He is the Head of 
the Engineering Department for Space Shuttle Flight Control and is technical director for 
Honeywell on the ACRV program. Clint started out at Vought years ago. He worked Scout, 
something near and dear to us at Langley. He worked on the Small Spinning Upper Stage and 
the shuttle program. Also he worked with Boeing on a roll channel automatic landing system for 
the Boeing 727. Clint, we do appreciate you coming very much. 

Next to Clint is John Hodgkinson from McDonnell Douglas Aerospace West in Long Beach. He 
is currently manager of Stability, Control, and Flying Qualities Technology and is responsible for 
methods development and research in these areas. Formerly he managed the YF-23 flight 
controls development at Northrop and was Director of Engineering Technology at Eidetics. He 
has served on two AGARD G&C working groups and the AIAA Atmospheric Flight Mechanics 
and GN&C technical committees. He teaches flying qualities at Northrop University where he is 
an Adjunct professor and is a lecturer in flight mechanics and stability and control at UCLA. 
Thank you, for taking time to be here. 

Our final panel member is Dave Leggett from Wright Laboratory. Dave graduated from Georgia 
Tech and the Air Force Institute of Technology where he got his masters degree. He has been 
with the Flying Qualities Group for the last twelve years and has worked on aircraft projects such 
as the NT-33, F15/STOL, the Maneuver Technology Demonstrator, and the Variable In-Flight 
Stability Test Aircraft (VISTA). He now has the awesome task of directing the research 
supporting the revision of MIL-STD-1797. Dave, we thank you for being here and I will go 
ahead and turn the session over to you now. 
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Dave Leggett 

The subject of this discussion is the direction of guidance navigation, and controls research 
needed to insure US competitiveness and leadership in aerospace technologies. I want to start 
off by saying one of our biggest challenges right now is the fact that research budgets are 
shrinking for absolutely everyone. One of the good things I heard in the last two days is talk of 
exchanging information and trying to set up channels of communication between different 
organizations. I think that we need to do more than just talk to one another. We are going to 
have to find ways to pool our resources and do joint research programs together — that is the only 
way we are going to be able to put enough resources, enough mass on a given problem to solve 
it. I am going to focus just on the Air Force, I will let some of my compatriots here talk about 
the civil side of things. 

I will start with where I think flying qualities needs some research. One of the areas we are 
particularly interested in is the development of standardized evaluation maneuvers for evaluating 
aircraft handling qualities. The lack of a standard set of evaluation maneuvers is part of the 
reason we have some discrepancies in our different flying qualities criteria and analysis methods. 
Another reason to develop standardized evaluation maneuvers was discovered by the review 
team during the digital flight control system development process review. We found out that, in 
a lot of cases, handling qualities testing has basically just become parameter ID. They just go up 
and do parameter ID and compare the numbers to the numbers in the spec. That was never the 
intent of the spec. We still intended aircraft handling qualities evaluation to be done using 
closed-loop evaluation by getting the pilot to really do some tasks and evaluate the aircraft for 
those tasks. In order to put that into the spec., as it seems now we are going to have to, we have 
to have some means of defining a standard task that we can use to compare all aircraft against. I 
think in the next few years we are going to be interested in developing a list of possible tasks to 
use as well as guidance to the SPO's on how to do those tasks. 

Another area we are going to be interested in is in resolving a lot of the discrepancies in the 
current handling qualities criteria and the handling qualities analysis methods. Although there is 
a good bit of agreement among a many of the different criteria and analysis methods, there are 
also areas where they disagree. It seems like everybody has their favorite criteria and that leads 
to a lot of people mistrusting the other criteria. I think we need to resolve that to make a better 
flying qualities spec. 

I will now move on to some other areas the Air Force is interested in. We seem to be expanding 
the envelopes of flight here and the Air Force is interested in what kind of capabilities those 
things will give them. A hot buzz word in recent years has been agility. I think Air Force 
interest in agility per se is kind of waning, there are a lot of reasons for that; however, 1 am not 
going to go into those now. There is one area of agility I think the Air Force is still very much 
interested in and that is high angle of attack. I think we are interested in trying to find out what 
we can do in that regime, how we can do it, and how we can control the airplane at high angles 
of attack. Another region of the expanding envelope that the Air Force is interested in is high- 
speed flight, or hypersonic flight. That is an area where if you just look at the budget, the Air 
Force budget for doing hypersonic research is shrinking. I do not think that is because of lack of 
interest, it is largely because of priorities and the overall budget is shrinking. Tha t is an are a 
where we have little data and we would like to know what can we do with that capability, how 
do we get it [the capability], and how do we control it. 

Another area of interest which is not really a flight regime, is new control responses and 
unconventional flight modes. Examples are a direct speed control or a speed hold mode, or a 
level turn mode. When the AFTI F- 1 6 or the F- 1 6 CCV flew, we tried a bunch of 
unconventional modes and in the case of several of them, the pilots could not find any particular 
need for them at the time. Interestingly, some F- 1 17 pilots came to talk to us about a year ago 
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and mentioned that they'd love to be able to turn without banking the airplane so I think there are 
opportunities for these kind of unconventional modes opening up. 

Another area that the Air Force is definitely interested in is application of multi-input/multi- 
output control design methods and other modern control methods. All those things go over my 
head so I do not think I will say too much about them other than to say that I know there are 
several offices in the Air Force that are definitely interested in pursuing these kinds of design 
methods. 

The Air Force is definitely interested in areas of research to reduce pilot workload. 1 saw a lot of 
things here in the last two days that were looking in that area, in particular the use of displays to 
help reduce the pilots workload. One of the things the Air Force is working on getting some 
standardization in display symbols and in display formats -- we have been sponsoring some 
research in that area. I think it would help pilots as they transition from one aircraft to another if 
they did not have to learn a whole new HUD whenever they go to another airplane. 

Another area in displays that I think might be being overlooked is display dynamics. If we are 
going to use displays to help the pilots do the tasks, if he is going to be depending on that display 
to do the job, then display dynamics are going to play a role in here too. In a lot of cases the 
displays depend on data from sensors which is filtered and that filter introduces dynamics that we 
are going to have to deal with. 

Another item in the area of reducing pilot workload is automatic flight modes. More and more 
of what the airplane is going to be doing in the future is going to be done automatically. We 
have had automatic landing systems for some time, though the Air Force is even interested in 
making them autonomous automatic landing systems. There are other automatic systems that we 
are putting the aircraft now too: automatic collision avoidance systems and so forth. Those help 
in one way, to reduce pilot workload, but I think we also need to give some consideration on 
what is going to be the pilot's role in a system where he is less and less the pilot and more and 
more the system manager. I think there is some things we are going to have to deal with and 
explore about how the pilot is going to interface with this system. 

Another thing the Air Force is interested in is new means and methods of generating forces and 
moments on the aircraft. Forebody vortex control is an example of that sort of thing. That is an 
area I do not know too much about but 1 do know that there are offices in the Air Force, 
particularly at Wright Lab, that are interested in that area. 

Finally, I think virtually every combat aircraft from here on out is going to pay a lot of attention 
to stealth technology, and for the guidance and control folks that is a new challenge. A lot of 
these Stealth airframes have some really nasty aerodynamic characteristics and yet at the same 
time they put restrictions on control surfaces: how many, the shape, the size, and how much we 
can move them. We are being asked to do a lot more with a lot less with these configurations 
and I think that is another challenge for us. 

At this point I think I will pass it onto you, John. I did manage to fill up the five minutes, did I 
not? 


John Hodgkinson 

We have a saying where I work that when, for example, we have to give a briefing to the vice 
president or something, it is time to raise the level of ambiguity of the discussion. That is really 
what I'm going to do for a minute. I’m going to talk on very ambiguous terms. 
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In asking what the direction of our research should be, we need to recognize that we [the 
aerospace industry] are a small analogue of what is happening in this country. So when you look 
at what comprises U.S. competitiveness and what is U.S. leadership, you think of certain 
categories of things that we do well, and things that we do not do so well. The things that we do 
not do so well are the things that are the focus of total quality management, such as cranking out 
products that are good, reliable, and on schedule, and talking to the customer. That kind of 
scheduled activity is one thing that, we are working very hard to do better and to compete better 
on. 

In the other category of things that we well, and which we do not focus sufficiently on, because it 
is much more difficult to quantify, is the unforeseen breakthrough research that proceeds from a 
brilliant insight. This nation, by virtue of its culture, has repeatedly provided such breakthroughs 
over the decades. It is a very difficult thing to manage, and it is a very difficult thing to fund. I 
know we all draw research schedules. We have five year plans - and I think my friends at St. 
Louis have ten year plans - for the research we are doing. It is very hard to imagine any 
breakthroughs happening on a ten year plan of that kind. However, the inspirational, 
exploratory research is something that we - and I believe this very, very strongly - should 
preserve in this country. 

Okay, I will be a little more specific now. Some statistics that I heard from Bruce Holmes really 
interested me. I think one of the statistics was that 83.7 percent of general aviation accidents had 
human factors as a contributing factor. I think that was the number - I wrote it down. It is 
certainly a very dramatic one [number]. We look very carefully at the statistics where I work and 
in the last thirty years of commercial airplane operations fifty percent of airplane losses have 
involved primary flight crew error. So it seems to me that we are doing an excellent job of 
making sure that control systems, structures, and so on are safe. Fail-safe technology twenty-or- 
so years ago dramatically improved airplane safety. I know we have experts here (at LaRC) on 
redundancy management and work is needed to insure that kind of thing continues. It seems to 
me, however, that the human element is the one area where the real pay dirt is in assuring 
further advances. Furthermore, we are fortunate in this country, because of a culture that 
encourages people to speak out, to have the kind of excellent test pilots (like Lee Person and Rob 
Rivers here, for example) that could be a big help to us. We [ the engineers / need to listen to 
those folks and they need to continue talking to us. 

Bottom line -- NASA and its partners need to focus on the inspirational kinds of research, the 
exploratory kinds of research and, furthermore, I'd suggest that we look at the human interfaces 
being an area that has a lot of payoff. 

Clint Browning 

I really appreciate the opportunity to be here and participate with these distinguished panel 
members and to be a part of this workshop program. I have just a few charts that I want to use to 
emphasize the area that we are addressing. I want to present the priority needs from the space 
standpoint and our overall aerospace industry [see figure 1], I realize this list is not complete and 
the more people I talk to within my company, the longer the list kept getting. I'm sure you can 
think of others that are important to competitiveness and leadership. The first item, which 
Howard mentioned this in his opening talk, is the heed to reduce launch operations cost. About 
this there can be no doubt. There is also, I think a great pay back to be gained from applying the 
so-called dual use technologies, the kinds of things that the military and commercial industry are 
working, that have application in space and sometimes vice versa. Shortening the design cycle is 
a critical area that we are all facing; the kind of time lines that we have been dealing with in the 
past, from both the schedule and resources standpoint just cannot continue. We have got to find 
ways to do it faster, quicker, and cheaper as well as with increased quality. [We need to ] 
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increase fault tolerance. [We need to] promote cooperative government Andustry joint research 
— which we heard some of these gentlemen already refer to. 


Space Vehicle GN&C - Priority Needs 

• Reduce Launch Operations Cost 

• Apply "Dual Use" Commercial and Military Technologies 

• Shorten the Design Cycle 

• Increase the Fault Tolerence 

• Promote Cooperative Govt/Industry Joint Research 


figure 1 - First Vu-Graph of Clint Browning's Talk 


To insure U. S. aerospace leadership, we must focus technology dollars to reduce the operations 
cost. One area that I believe would have benefits is to reduce the complexity. Systems like the 
space shuttle have a tremendous amount of complexity to them. On a system like the shutde 
there may be sixty or eighty subcontractors providing LRU'S for the avionics. Reducing the 
actual number of LRU'S, the interfaces, simplifying the certification/verification/check out 
process, and improving the system reliability and availability all potentially reduce launch delays 
due to system complexity. We need to make avionics cheaper. Using commercial off the shelf 
components may be the way to go. One area for space that has to be a concern is the radiation 
effects, the SEU tolerance has to be considered. I might also mention an area that needs, I 
believe to be seriously looked at, is the S level parts requirement that has been imposed upon 
space avionics components. With today's total quality management, perhaps the thing that needs 
to be done is to certify a process and a company that is producing very high quality parts and not 
impose the S level in all areas. Also lets get vehicle health management out of the talking stage, 
integrate and demonstrate the use of sensors, the diagnostics, and the processing for self 
monitoring. The expected pay-off is to reduce the army that required to launch these vehicles. 
These areas are not new to anyone but I think they are certainly areas that need dollars and 
technology research applied. 


In navigation a lot of work is being done in integrated autonomous navigation, particularly 
related to die GPS inertial navigation systems and particularly in the terminal phases of the 
missions where the differential mode has added high accuracy to the GPS approach. There is a 
lot of work going on in avionics companies with highly fault tolerant INS/GPS combinations. 1 
think these are areas that navigation can help in terms of competitiveness, and even the part that 
the GPS might play in the attitude determination. 

I might just break right here and say, personally, and I think from our standpoint at Honeywell, 
I'm very impressed with the research this is going on throughout this organization from what we 
heard over the last two days and we are relating to some of what has been said here. 

In automation, the cockpit displays and hand controls is an important area. Do you go on up to 
the six degree of freedom hand controls? This whole area of the role of the crew versus 
automation has been mentioned, and that applies not only to the cockpit crew but to the ground 
crews. What is the role of those that are working on the preparation for the launch? What is the 
role of those that are on board the vehicle and the impact on autoland and safety. Due to 
physical deterioration in space, aut olan d becomes more and more critical the longer people stay 
in space. It will be more of a consideration for the sixteen day orbiter, moving on up to a twenty 
eight day orbiter, and perhaps longer for moon and Mars missions. It is generally felt that 
autoland is an absolute necessity. Advanced guidance concepts are required to expand flight 
envelopes, and therefore not be so dependent upon the weather, both for launch and return. 
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A high level of functional integration and fewer boxes has been a focus in the military arena. 
Flight control, navigation, the processors, air data, radar altimeter, and perhaps terrain following 
can be combined into a single small avionics box. I think there is a lot of promise there, in terms 
of reducing the complexity and the number of interfaces to be dealt with. A lot of good work is 
going on in these areas. We do need a practical application and demonstration in some real life 
examples. 

Reducing the design, test, verification, and integration cycle is very important. Integrated 
product development using integrated product teams can be cost effective by bringing different 
disciplines together, cutting down the time for serial functions, and performing parallel 
functions. I this believe ought to be encouraged and has great potential and we see many 
companies beginning to adopt this approach. Rapid prototyping, going all the way from the 
requirements/specifications through the analysis and design and the automatic code generation to 
the hardware and the integration, testing, and check out, has a tremendous opportunity to offer a 
competitiveness advantage which ought to all be encouraged. We have seen some indications of 
a three to five hundred percent productivity increase. What normally might take two hundred 
dollars as an industry standard to generate a line of ADA code is reduced to the twenty dollar 
range, which I think ought to continually be explored. 

The Tagutchi design of experiments approach should be applied not only to the front end of the 
development process but as the systems analysis progresses application to the production 
manufacturing area and tests will reduce the test matrices associated with all the combinations 
and the parameters that have to be tested. Even application into the wind tunnel testing should 
reduce the amount of tunnel time required. 

The need for increased fault tolerance in some ways flies in the face of the need to reduce 
complexity. The Space Shuttle quad system is tremendously complex and expensive, yet many 
of the unmanned launch vehicles have had a single string failure point in which a single failure 
will ruin the mission. Now we are seeing more and more of the launch vehicle companies begin 
to look at the increased fault tolerance because the cost of the payloads is becoming prohibitive 
to lose. There is a balance that must be found. The use of the standard buses and the open 
architecture’s using modular approaches to help make the avionics easier to integrate. 

The last direction is to actively promote joint government research where government in many 
cases does provide some study funds or in the cases of memorandums of understanding where 
both put up some funds for proof of concept . We had an excellent cooperative arrangement with 
NASA/Langley on the 737 INS/GPS autoland test. This helps get some things started that if 
industry or just the government kept them to themselves, it might not flourish. I must say on the 
other side of that coin though that industry is in business to make money and if this is all that 
ever happens, there is no pay back and there is no way that we can survive. There has to be some 
hope of a program or project, a way to sell something and to make some money. Many times 
companies are penalized for doing this. It might be best, from a business standpoint, to stand 
back and let somebody invest their money waiting for the proof of the concept and then step in 
and build something. There is another side of this that we really must watch and be careful 
because by the time the government gets ready to deploy a system, anybody could come and 
figure out bowlbWraJWiia it Many companies started out on the INS/GPS research years 
ago. By the time that it is deployed or certified for flight, there is fifty competitors out there that 
can build and market the system. How do you help make it attractive for companies to do this 
kind of research? It is not the subject for a technical audience but you may find some companies 
are reluctant to engage in this research so I raise it as an issue. Thank you very much. 
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Tom Richardson 


First of all, I want to thank you for inviting me. This has been very interesting and illuminating 
to see the whole of guidance/navigation/control at NASA/Langley and some the Air Force effort. 
Second of all, I want to thank all of you hard-core attendees for staying around on a Friday 
afternoon. I looked at panel discussion on the program and I thought, well my goodness, there is 
going to be about five people out there on Friday afternoon — so thanks for sticking in. I think it 
is worthwhile. None of us [on the panel] collaborated on what we were going to say but a lot of 
the themes are similar and I think the big drivers are the shrinking budgets and also the need to 
do better. These two factors are somewhat at odds, but I think we (in the research community) 
have got to do better and can do better. We do that by improving efficiency and by focusing our 
research. 

One of the things I want to hit on in particular is focusing our research. We saw a lot of 
tremendous papers today and it is good to see all this basic research going on and I think that it 
ought to continue. When I look at the way aerospace research is defined, I see two basic 
varieties. There is basic research, which is far term, and applied research, which always has a 
near term payoff and has some other attributes. It is kind of gray as to where near term and far 
term is, but some things people at LaRC work with are clearly far term. Often you can't see 
where the research is going and maybe only twenty five percent of those efforts will be 
successful. But that basic research should go on — because of that twenty five percent. I'd like to 
direct my subsequent comments more to what I would call applied research, things that have 
more of a near term payoff and that are going to be applied to our critical national needs. The 
application could be military or civilian. 

I made a list! I made a list [see figure 2] of some of the big things. I may have missed some 
things, but I think it is important to develop a list to kind of categorize things. You have to 
market the research we do to the folks that control the money and I do not see how you can do it 
without prioritizing things. 


GN&C - Priority Needs 


• PIO 

• FBL/PBW 

• Design Process 

• Airplane sizing and concept development 

• Development of the airplane database 

• Rapid prototyping of simulations 

• Testing Methods 

• Multivariable Nonlinear Control Design Methods 

• Real Time Trajectory Generation 

Figure 2 - First Vu-Graph of Tom Richardson's Talk 


Pilot Induced Oscillation (PIO) 

It keeps coming up. It has been known for years and my feeling is, the reason it is never solved, 
is that every time it happens the program manager gets by it somehow and says "Well, that is it, 
we have gotten that out of the way," and hopes that it will never happen again. Of course it does 
happen again and it is a big thing. It is probably one of the biggest problems we have inflight 
controls. If you want to focus problems in the controls area, pilot induced oscillation is a choice 
with which I agree wholeheartedly. We need some standards, we need to agree on what the 
criteria is that we are working towards, and we need to agree on some kind of design process. If 
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you are talking PIO, then pretty soon you see the need for a better simulation of a pilot and their 
dynamic response. There is a lot to be done in this area (PIO) but it is a very important area. 

EIy..l2y.. Liaht/PQ w gr by W ire 

This term may be a little bit constrictive, as it really should be something like Advanced Vehicle 
Management Systems. That is the title the Air Force gives it. There is a real need for research in 
this area, which addresses the question of how do you implement these complex systems that are 
feasible now. The guidance/navigation/control function at NASA Langley is kind of the way we 
organize thing. In my area, we focus more the algorithm development However we work very 
closely with the people that do the actual implementations and are concerned with system 
architecture aspects. I think that is important, so I look along this Fly by Light/Power by Wire 
task as addressing the overall system architecture. There are many issues. What is the best way 
to blend photons and electricity? How do you best do it, how do you get by with the minimum 
amount of equipment to achieve redundancy or are you just going to go QUAD every time? 
There is a lot of weight involved and there is a lot of cost. In fact, one of the big drivers now in 
the work we do is cost. 

Design Pro cess 

Everybody is mentioning the design process. It is very important that we have a good 
understanding of what our process is. It is hard to quantify. The reason it is hard [to quantify] is 
because it is not only events that happen, it is they happen in certain times in the design process 
and there is a lot of feedback. Getting that [the design process] nailed down where everybody 
understands what is to happen is crucial. It is got to be done faster. We have to figure out ways 
to automate things. Things like automatic code generation will help. 

A irp lang_si zin g a n d concep t d eve lop m ent 

There is lots of other issues in airplane sizing and concept development. We have mentioned 
agility. I do not know if everybody appreciated what they are talking about in the agility study 
but what is important is more of the up front work when you are sizing the airplane, that you do 
not just size it to performance. You should size it for maneuvering and I think that is very 
important. Even if it is done very simplistically, it needs to be done up front. Otherwise they are 
going to give you an airplane and say, "Okay there it is, go make it fly, ... by the way we want to 
go zero to ninety degrees bank angle in a quarter of a second." So, there is a lot of work, there is 
a lot of activity that is done in the early sizing and concept development. If the flight controls 
people do not participate in that , or if we are too slow , we get left in the dust . I have been on a 
lot of programs where you just got a new program, you are all happy and settling in and they say 
"Oh, the flight control systems spec, has to be out in three weeks" and you barely have time to 
type it in that time and they say "Well, put it out and we’ll fix it later on when we get a little bit 
smarter" and you know how that goes. 

Development of the Airplane Database 

This is very critical and it kind of goes in with airplane concept development [,which is discussed 
above]. I think we need more analytical methods and less dependence on a wind tunnels. We 
have some very good panel methods. There is the PANAIR code [at Boeing], there is vortex 
lattice, there is things can give you a quick answer — not the best answer maybe, but codes that 
can give you a quick answer to get you going. We have to think about ways to do database 
development more quickly and have less reliance on the big ticket items. Wind tunnel testing is 
still a big ticket item. In a major program like the F22, the relative cost of wind tunnel testing is 
not so high. Testing is especially a big ticket item when you are in the some R&D program 
where you have got some limited funds to put some things together. Here, the cost of wind 
tunnel testing can wipe out your entire program. 
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Rapid Prototyping 

This is important in all areas, and in simulation in particular. There is a lot of comment about the 
portability of software, and I strongly feel that we ought to be able to run our simulations at our 
work bench and have that same code run in the real time environment. That give is you two 
things. One, it gives you speed. You can transition more quickly, you do not have to go back 
and recheck the thing out in real time, with everybody sitting around watching you. Two, it lets 
you control the database. You have got the database in your area, and you do not have to worry 
because you have one [database] and somebody else has another and you can never figure out 
who has the right one. Code portability puts more of the focus [of database control] on the 
people doing the work. This is critical. All of the technology for creating this good situation is 
there. It is a matter of organizing it [the technology] and figuring out how to make it work. 

There is a lot of near term payoff here. We have done a lot of work in this area at Boeing and it 
has been very fruitful. 

Testing Methods 

A paper presented earlier described flutter testing and procedures used to come up on the flutter 
point, an unstable situation. The techniques described in that presentation can be applied to any 
test situation, particularly of something that has conditional stability. The investigation of PIO 
comes to mind. We need more formalized methods. This is an area that can have important near 
term payoffs if worked. 


Multivariable Nonlinear Control Design methods 

Many of the methods at technologies in this area are mature. We have some excellent methods. 
For the near term, they [the methods] need to be packaged. I am excited about an Air Force 
program , "Design Guidelines for Multivariable Control", that will attempt to systematize this 
area. They [the Air Force] are going to apply modem methods to some Air Force aircraft. 


Real Time Trajectory Generation 

We need real fast algorithms that work reliably and automatically. They [the algorithms] need to 
be robust. They really need to work in real time. The need occurs all the time, particularly in 
military aircraft. Something happens on a mission and the pilot must replan. This is a big 
problem. The pilot is faced with a 4D navigation and optimization problem with N constraints. 
The constraints may be involve survivability, fuel state, and wind conditions. Something to give 
a quick, not necessarily completely optimal, answer is required. Genetic algorithms may be 
fruitful here. 


Well, that is my list. It is not an exhaustive list, it just the ones I know about. I should mention 
that the order of the list is not intended to reflect priority. The order is simply the order that these 
issue occurred to me. 

The final chart [figure 3] I have labeled "Panel Action", but the action is really for everyone. 
Come up with a [prioritized] list of the applied research to be done. 
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Panel Action 


Priority list of applied research - problem statement 
Objective - vision of the future 
Plan for validating technology 


'^Figure 3 - Second Vu-Graph of Tom Richardson's Talk ^ 


Problem Statement 

Creating the list must proceed from the problem statement. One should start with the question, 
"What are the problems we have with aerospace vehicle design?" 

Objective - vision of the future 

We need to ask: "What is the objective? What are we trying to get out of all this?" We need to 
have some vision of the future, of what we want to exist 3-5 years from now. We might say, 
"We want to have the ability to quickly do these simulations and not have to fool around with 
these ways that we have always done them in the past." 

Plan for v alidating technology. 

We need a plan for validating the technology developed. Some of the work required here is in 
place, some needs help. 

That is pretty much all I had. Thank you very much. 


[The panel then moved to a question and answer period that was not readily transcribed. 
However, the videotape of the entire panel discussion, including the question and answer period, 
is easily followed by someone with a technical background and a copy may be obtained from the 
LaRC GNCTC. - Editor] 
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